近期在學習JAVA的課程中，聽到老師分享過去在職場上的＂小朋友吵架＂，台下的我感同身受的會心一笑，在過去這些年也曾經歷過這樣的＂小朋友吵架＂。

Ａ：這不是你該想到的嗎？
Ｂ：你需求上又沒有說？
ｃｊｋｓｏｒｕｔｍｌ；ｄｓｊｆ　

相信這樣的場景應該不陌生……正是，工程師跟專案的例常對話。這樣的日常甚至還開發成line 貼圖商品，提供交流工程師與PM的交流 XD。

有合作經驗的靠默契(又稱通靈)，沒合作經驗的，總得經過碰撞。後果就會很兩極．．．．
為了避免＂我說的很清楚，你聽的很模糊＂之負面效果產生，於是文字化的書面資料就此誕生，也就是稱為＂規格書＂的文件。

但是規格書到底該寫些什麼呢？

回顧過去的開發經驗，整理出來的幾點歸納：

• 需求訪談：既然是訪談就有對象，因此就有需求文件(規格書)，需要讓＂對象＂了解、明白所開發的系統內容，雙放認知是否一至。
• 對象有：使用者、老闆、開發人員（設計師、前端、後端、IT．．．．）
• 語言：既然對方分布如此廣泛，利益關係人所在乎的角度也不同，因為針對不同角色還需要說他們的語言。
  • 好比：使用者在乎，介面會長怎樣？有哪些圖片需求、按鈕配置，操作方便嗎？有沒有防呆機制？
  • 老闆、長官在乎：會不會帶來效益？會不會事半功倍？開發時程的成本問題等等
  • 開發人員的語言更多了，依負責區塊所使用的語言不同，設計師、前端工程師看UXUI的流程動線、圖片按鈕配置、視覺美感效果。後端工程師看功能的流程、哪個功能產生什麼結果，該撈取哪個資料呈現？需不需要資料庫規劃？可以使用那些API，需不需要重寫API？如何部署等…

規格書 之 Spec撰寫

原來一份規格書需要包含這麼多的項目，視覺流程圖：有畫面、有流程、有規則。資料庫的規劃，

有各種資料及資料交換、呈現邏輯。

規格書沒有一定的標準，但是要能傳遞與系統有關之人員所需之知曉的部分。

介面、畫面流程明確最最重要，因此條目綱要分明、畫面簡潔有條理，一致性排版，增加閱讀易懂性。BUT 筆者接觸過的工程師其實不喜歡"閱讀"，寧願看圖，透過UML就是一種跟RD對話最好的重點精華。

好比：

• 使用情境用Use Case
• 使用情節系統流程用Flow Chart / 循序圖 或 泳道圖
• 資料庫設計上ER-D 使用類別圖，呈現資料上下層關係….
• 系統的元件、部署（元件部署圖）、以及設計….C4-Model、類別庫..MVC…..等

上述最後一點也是筆者進修JAVA語言的主因….

綱要條目分明，善用圖解，表達功能需求，將因果關係列出來，如此一來在雙方溝通認知上，不至於瞎子摸象，想像認知偏差導致打掉重練，勞心勞力還烏煙瘴氣。

規格書的重要性也是保障雙方權益，避免各說各話喔～